The current WebSocket API specifies the ability for multiple protocols
to be specified in the constructor of the WebSocket object. The
current WebSocket protocol spec doesn't specifically preclude
specifying a list of protocols in the Sec-WebSocket-Protocol request
header, however it doesn't specify it either. The following changes to
the -02 spec text remedy this oversight.

-------------------------------
1.3. Opening handshake
page 9
replace the sentence "The |Sec-WebSocket-Protocol| field takes an
arbitrary string:", and the following paragraph with:

The Sec-WebSocket-Protocol request-header field can be used to
indicate what subprotocols (application-level protocols layered over
the WebSocket protocol) that are acceptable to the client. The server
selects one of the acceptable protocols and echoes that value in its
handshake to indicate that it has selected that protocol.

        Sec-WebSocket-Protocol: chat, superchat

-------------------------------
1.3. Opening handshake
page 11
replace the paragraph beginning "Option fields can also be included."
with the following:

   Option fields can also be included.  In this version of the protocol,
   the main option field is |Sec-WebSocket-Protocol|, which indicates
   the subprotocol that the server has selected.  Web browsers verify
   that the server included one of the values as was specified in the
   |WebSocket| constructor. A server that supports multiple
   subprotocols has to make sure it selects one based on the
   client's handshake and specifies it in its handshake.

        Sec-WebSocket-Protocol: chat

-------------------------------
1.9. Subprotocols using the WebSocket protocol
page 14, paragraph 1
Replace the sentence "If it is specified, the server needs to include
the same field and value in its response for the connection to be
established." with:

If it is specified, the server needs to include the same field and one
of the selected subprotocol values in its response for the connection
to be established.

-------------------------------
5.1. Client Requirements
page 28

Replace item 16 with:

   16.  If there is no /protocols/, then skip this step.

        Otherwise, generate the acceptable protocol string by joining
        each protocol in /protocols/ using a U+002C COMMA character
        followed by a U+0020 SPACE character. Add the string
        consisting of the concatenation of the string
        "Sec-WebSocket-Protocol:", a U+0020 SPACE character, and
        the acceptable protocol string generated above, to /fields/.

-------------------------------
5.1. Client Requirements
page 34

Replace the entry beginning "If the entry's name is
"sec-websocket-protocol" with:

        -> If the entry's name is "sec-websocket-protocol"
           If there was are /protocols/ specified, and the value is not
           exactly equal to one of the items in /protocols/, then fail
           the WebSocket connection and abort these steps.  (If
           no /protocols/ were specified, the field is ignored.)

-------------------------------
5.2.2. Sending the server's opening handshake
page 40

In the section "/subprotocol/", replace the sentence beginning "If the
server supports multiple subprotocols" with:

If the server supports multiple subprotocols, then the value should be
derived from the client's handshake, specifically by selecting one of
the values from the "Sec-WebSocket-Protocol" field.

-------------------------------

There doesn't appear to be a place to define it in the current spec,
but should it be added, I have included a description of this request
header. Using definitions from
<http://dev.w3.org/html5/websockets/#dom-websocket> is U+0021 to
U+007E and <http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html#sec2>:

Sec-WebSocket-Protocol = "Sec-WebSocket-Protocol" ":"
        protocol *( SP protocol )
protocol = 1*<any CHAR except CTLs, separators, or SP>

For more consistency with HTTP and the well-defined concept of
acceptance lists with quality values, and also making it easier for a
HTTP server to reuse the same code, I propose that the following
definition to have acceptance lists for the subprotocol. Note however
that since this also requires a change to the WebSocket API it may not
be possible or desirable.

Sec-WebSocket-Protocol = "Sec-WebSocket-Protocol" ":"
        1#( ( protocol )[ ";" "q" "=" qvalue ] )
protocol = token


Regards,
Brodie